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(§) General transport layer gateway for heterogeneous networks. 



@ A multiprotocol transport network (MPTN) 
gateway provides transparent interconnection 
of two or more SPTNs (12, 14, 16, 18) running 
different transport layer protocols to form an 
integrated heterogeneous MPTN. The MPTN 
gateway of the present invention has no depen- 
dencies on the particular transport protocols 
running on the SPTNs being interconnected as 
it utilizes a common transport provider (a Gate- 
way Services Protocol Boundary (GSPB)) (38) 
between the SPTN transport protocols and the 
gateway components. The MPTN gateway sup- 
ports connections between end systems across 
multiple intermediate networks. The MPTN 
gateway provides automatic routing based on 
dynamic participation in the routing protocols 
of the interconnected SPTNs so that any num- 
ber of gateways may be interconnected and in 
any topology desired. As the MPTN gateway has 
a general architecture and acquires routing 
information automatically, it supports not only 
other MPTN nodes and gateways but also 
non-MPTN nodes and gateways. 
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Related Applicati ns and Patents 

This application is closely related to our own, 
commonly assigned U. S. Patent No. 5,224,098, en- 
titled "Compensation for Mismatched Transport Pro- s 
tocols in a Data Communication Network". The patent 
describes a Multi-Protocol Transport Networking 
(MPTN) Architecture which allows an application pro- 
gram running at one node in a network to communi- 
cate with a second application program running at an- 10 
other node in the network even where the application 
programming interface (API) assumes a different set 
of transport functions than those supported by the 
transport provider. In particular, it relates to a method 
for establishing communication, either connection- is 
less or with a connection, between the applications 
and compensating for transport protocol mismatches, 
if any. 

This application is also related to another one of 
our own, commonly assigned, copending application 20 
serial number 07/915,969, filed July 16, 1992, enti- 
tled "Protocol Selection and Address Resolution for 
Programs Running in Heterogeneous Networks". 
This copending application relates to address resolu- 
tion and protocol selection among multiple transport 25 
protocols for the applications and the nodes in the 
MPTN. 

This application is further related to another one 
of our own, commonly assigned, copending applica- 
tion, filed May 27, 1993, Serial No. 08/58,351, enti- 30 
tied "Inter-Domain Multicast Routing". This copend- 
ing application relates to a method of and system for 
multicasting messages in a complex network that is 
originally equipped only for unicast transmission. 

BACKGROUND OF THE INVENTION 

I. Field of the Invention 



The present invention relates to data communica- 
tions and, more particularly, to a gateway which pro- 
vides transparent interconnection of two or more net- 
works running different protocols. 

II. Background and Prior Art 

As communications network have evolved, inde- 



40 



45 



pendent suppliers of computer hardware and soft- 
ware developed different, non-compatible formats 
and protocols for transporting data through the com- so 
munications networks. Examples of well-known com- 
munications protocols include System Network Archi- 
tects (SNA), Digital Network Architecture (DEC- 
Net), Transmission Control Protocol/Internet Protocol 
(TCP/IP), NetBIOS and OSI. 55 

As networks hav grown, and particularly as lo- 
cal area n t works (LANs) have come into widespr ad 
use, many organizations have ended up with one or 



more physical n tworks that are confederations of 
one or more logical networks, ach logical network 
running a different networking protocol. (A logical 
network runs a single networking protocol and is re- 
ferred to a single protocol transport network, or 
SPTN.) For example, a single organization may hav 
dozens of SPTNs running as many as four or five dif- 
ferent networking protocols. (Such a physical net- 
work having more than one logical networks, or 
SPTNs, is termed heterogeneous network.) This het- 
erogeneity complicates communications as distribut- 
ed programs are generally written for a particular ap- 
plication programming interface (API) which assumes 
a specific networking protocol, and can, therefore, 
only run on limited parts of the overall physical net- 
work. 

In a node, if a mismatch exists between the trans- 
port protocols (the most basic end-to-end networking 
protocols for opening and closing connections, send- 
ing and receiving data on connections, and sending 
and receiving datagrams) assumed by the particular 
API for a company's application program and the 
transport protocols actually implemented in one or 
more of the SPTNs on which the company would like 
to transport the application data, compensation be- 
tween the API and the transport provider may be re- 
quired. This is described in greater detail in closely re- 
lated U. S. Patent No. 5,224,098. 

In addition, there are addressing problems asso- 
ciated with the heterogeneous networks. A program 
today identifies itself and finds its partners using ad- 
dresses associated with a particular networking pro- 
tocol. (A networking protocol uses addresses to lo- 
cate programs in the SPTN via existing protocol-spe- 
cific means, such as local directory searches or direc- 
tory broadcasts, and to route to those programs.) In 
order for the program to operate over multiple, differ- 
ent networking protocols, such as in a heterogeneous 
network, a mechanism is needed to bridge the gap 
between the specific address set used by the pro- 
gram and the address sets used by the networking 
protocols. In particular, program independence from 
specific network protocols requires a trans port- inde- 
pendent mechanism for finding the source and des- 
tination application programs and the corresponding 
available transport protocols. In addition, a mecha- 
n is m for s ele cting th e b e st t ran s p o r t pro t ocol t o uti l - 

ize. when multiple networking protocols are available, 
is required. This is described in greater detail in closed 
ly related patent application Serial Number 
07/915,969. 

Where there are a number of SPTNs running dif- 
ferent protocols, a gateway provides transparent in- 
terconn ctionofth SPTNs so that a singl multipro- 
tocol transport network, or MPTN, is formed. This 
MPTN appears to the end user applications, as if a 
single protocol was used throughout the heterogene- 
ous network. Gateways, among other things, provide 
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routing functions in order to enable resources to be lo- 
cated and to relay data between the SPTNs to ach- 
ieve end-to-end connectivity. 

Present gateways, how v r, have many limita- 
tions making the interconnection of networks running 5 
different protocols non-transparent, if the intercon- 
nection is even possible. For instance, present gate- 
ways are transport layer protocol-specific. An exam- 
ple of a transport layer protocol-specific gateway is 
one which is able to interconnect a network running 10 
one flavor of OSI with another network running an- 
other flavor of OSI. This gateway is not able to inter- 
connect other types of networks, for example a net- 
work running TCP/IP and a network running SNA. 
More detail is given on an OSI gateway in an article 15 
entitled "An Approach to CO/CL Internetworking", 
CO/CL Internetworking Workshop, July 24-26, 1990. 

Another problem with present gateways is that a 
maximum of two networks may be interconnected, 
i.e., one gateway being used between the two inter- 20 
connected networks. No additional networks may be 
added so that one continuous heterogeneous net- 
work may be formed. 

Further, with current gateway solutions, all nodes 
in an SPTN must be upgraded to include additional 25 
functions and protocols in order to operate with the 
gateway. This is not feasible in many environments 
due to the large number of nodes and cost 

There is a need for a transport layer gateway that 
has a general architecture so that is has no depend- 30 
encies on the transport protocols being supported by 
the interconnected networks. Also, there is a require- 
ment for such a gateway to support connectivity 
across multiple SPTNs. This gateway should also 
support existing nodes running existing protocols that 35 
cannot be upgraded to include new functions. 

SUMMARY OF THE INVENTION 

A multiprotocol transport networking (MPTN) 40 
gateway provides transparent interconnection of two 
or more SPTNs running different transport layer pro- 
tocols to form an integrated heterogeneous MPTN. 
The MPTN gateway of the present invention has no 
dependencies on the particular transport protocols 45 
running on the SPTNs being interconnected as it util- 
izes a common interface (a Gateway Services Proto- 
col Boundary (GSPB)) between the SPTN transport 
protocols and the gateway components. The MPTN 
gateway supports connections between end systems so 
across multiple intermediate networks. The MPTN 
gateway provides automatic routing based on dynam- 
ic participation in the routing protocols of the intercon- 
nected SPTNs so that any number of gateways may 
be interconnect d and in any topology desired. As the 55 
MPTN gateway has a general architecture and ac- 
quires routing information automatically, it supports 
not only other MPTN nodes and gateways but also 



non-MPTN nodes and gateways. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the technical description concludes with 
claims particularly pointing out and distinctly claim- 
ing that which is regarded as the invention, details of 
a preferred embodiment of the invention may be more 
readily ascertained from the following technical de- 
scription when read in conjunction with the accompa- 
nying drawings, where: 

Fig. 1 is a diagram illustrating a multiprotocol 
transport network (MPTN) consisting of a number of 
single protocol transport networks (SPTNs) intercon- 
nected by MPTN gateways of the present invention. 

Fig. 2 depicts the MPTN gateway of the present 
invention in block diagram form. 

Fig. 3 depicts the basic format of a basic link unit 
(BLU) which is received by the MPTN gateway of the 
present invention from a native node. 

Fig. 4 depicts the basic format of a BLU which is 
received by the MPTN gateway of the present inven- 
tion from an MPTN node. 

Fig. 5 illustrates the flow of messages and other 
information exchanged between a native node on an 
SPTN and the various elements of the MPTN gate- 
way when the native node issues a native search re- 
quest. 

Fig. 5A illustrates, in flow chart form, the proce- 
dure followed by the Routing Services Element when 
routing information is requested. 

Figs. 6A and 6B illustrate the flow of messages 
and other information exchanged between an MPTN 
gateway, a native node on an SPTN and the various 
elements of the MPTN gateway when the MPTN gate- 
way issues an MPTN search request. " 

Fig. 7 illustrates the flow of messages and other 
information exchanged between a native node on an 
SPTN and the various elements of the MPTN gate- 
way when the native node is advertising routing infor- 
mation to the MPTN Gateway. 

Fig. 8 illustrates the flow of messages and other 
information exchanged between a native node on an 
SPTN and the various elements of the MPTN gate- 
way when the MPTN gateway is advertising routing 
information to the native node. 

Fig. 9 illustrates the flow of messages and other 
information exchanged between nodes on the SPTNs 
and the various elements of the MPTN gateway dur- 
ing the conveyance of a datagram between a Native 
Node on one SPTN and another node on another 
SPTN. 

Fig. 1 0 illustrates the flow of messages and other 
information exchanged between nodes on the SPTNs 
and the various elements of the MPTN gateway dur- 
ing the conveyance of a datagram between an MPTN 
node on one SPTN and another node on another 
SPTN. 
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Figs. 11a and 11b illustrate th flow of messages 
and other information exchanged betw en nodes on 
the SPTNs and the various elements of the MPTN 
gateway during th establishment of a connection be- 
tween a Native Node on one SPTN and another node 
on another SPTN. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 
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Figure 1 is a high-level block diagram of a multi- 
protocol transport network (MPTN) 10 consisting of 
five independent single protocol transport networks 
(SPTNs): an OSI SPTN (N osl 12), a TCP/IP SPTN 
(N TC P 14), an SNA SPTN (N SNA 16), a NetBIOS SPTN 15 
(NwetBios 18), and a second SNA SPTN (N SNA 19). 
Each SPTN implements a different communication 
protocol. In particular, in this example, N OS i 12 imple- 
ments the OSI communication protocol stack, N TCP 14 
operates under the TCP/IP protocol, N SNA 16 operates 20 
using the SNA communication protocol, and so forth. 

Each of the SPTNs has nodes connected thereto. 
In particular, N os , 12 has nodes ND1 20 and ND2 21, 
N TCP 14 has node ND3 22, N SNA 16 has node ND4 23, 
NNetBios 18 has node ND5 24 and N SNA 19 has nodes 25 
ND6 25 and ND7 26. For simplicity, each SPTN is 
shown having only one or two nodes but in reality can 
have any number of nodes. 

Some of these nodes are MPTN access nodes 
while others are non-MPTN access nodes or native 
nodes. MPTN access nodes are discussed in great 
detail in U. S. Patent No. 5,224,098 and copending 
application serial number 07/915,969. In the figure, 
there are three MPTN Access Nodes, ND1 20, ND5 
24 and ND6 25. For the purposes of this specification, 
an MPTN access node is an end node which allows 
a first transport user (29a, for example) conforming to 
a particular protocol interface definition, SNA, in this 
example, to use a transport provider (31a) conform- 
ing to a different protocol interface definition, OSI, for 40 
conveying information over an MPTN to another 
transport user (29c) conforming to the first transport 
user's protocol interface definition (SNA). This com- 
munication may be over any number of SPTNs and 
protocols and is shown in Figure 1 as dashed line 33a. 45 
As can be seen, the communication between N os , 
and N NetB[OS is conveyed by an MPTN gateway (GW1 



30 



35 



30) which will be discussed in further detail below. 

Similarly, some of the nodes are non-MPTN 
nodes, or native nodes. In the figure, there are four 50 
native nodes, ND2 21 , ND3 22, ND4 23 and ND7 26. 
A native node for the purposes of this specification is 
a node having a transport us r 29d which conforms 
to the same protocol interface definition (OSI, in this 

xample) as its transport provider (31 b). Communica- 55 
tion betw en a transport user 29d of a nativ node 
ND2 21 and anoth r transport user 29 of an MPTN 
Access Node ND6 25 is shown by dashed line 33b. 



The vast majority of presently installed nodes in to- 
day's networks are native nodes. 

Interconnecting the SPTNs Nqsi 12, N TCP 14, 
Nsna 1 6, N NetBIO s 1 8, and N S ma 1 9 are MPTN gateways 
(GW1 30 and GW2 32) of the present invention. The 
MPTN gateway of the present invention has no de- 
pendencies on the transport protocols being connect- 
ed, is able to concatenate two or more SPTNs to form 
the end-to-end connection, provides automatic rout- 
ing based upon dynamic participation in the routing 
protocols of the concatenated SPTNs, and supports 
both MPTN and native nodes. 

Figure 2 illustrates the MPTN Gateway 30 of the 
present invention in block diagram form connected to 
SPTNs N osl 12, N TCP 14, N SNA 16 and N NetBIOS 18. 
Gateway 30 consists of a plurality of Transport Pro- 
viders TPros, 34a, TPr TCP 34b, TPr SNA 34c and TPr Net . 
bios 34d. These Transport Providers define the trans- 
port protocols that are actually implemented when 
data is exchanged between nodes (or gateways) on 
one SPTN, plus new MPTN protocols (or deltas) to 
support non-MPTN nodes . In this example, TProsi 
implements the TCP protocol plus deltas, and so 
forth. Each of the Transport Providers performs all of 
the transport provider-specific functions in the MPTN 
Gateway. Only four Transport Providers are shown al- 
though any number of providers may be implemented 
in Gateway 30. 

MPTN Gateway 30 further consists of an MPTN 
General Services Element 36 which is logically con- 
nected to each of the Transport Providers. MPTN 
General Services Element 36 provides various ser- 
vices for the Gateway 30, none of which are transport 
protocol-specific. MPTN General Services Element 
36 is separated from the Transport Providers by a 
Gateway Services Protocol Boundary (GSPB) 38 
which defines the interface between the Transport 
Providers 34a, 34b, 34c, and 34d and the MPTN Gen- 
eral Services Element 36. Above the GSPB, no trans- 
port protocol-specific functions occur. 

The use of the GSPB is important for a number 
of reasons. First, separating the MPTN General Ser- 
vices Element from the specific Transport Providers 
allows the MPTN General Services Element to be in- 
dependent from the underlying Transport Providers. 

Second, a mapping can be defined from each 
s upport e d Prov i d e r to t h e GSPB and vice versa. T his 



allows a much easier definition of mappings between 
supported Transport Providers. Rather than defining 
the mapping from each supported Transport Provider 
to each other Transport Provider (an 0(N 2 ) problem), 
all that is required is to define the mapping from each 
supported Transport Provider to the general form (an 
O(N) problem). 

Third, nabling a new Transport Provid rto b a 
part of an MPTN gateway is simple. The new Trans- 
port Provider merely has to map its transport protocol 
to the GSPB. This allows a Transport Provider to be 
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installed without requiring changes to the MPTN Gen- 
eral Services Element 36. 

MPTN General S rvices Element 36 consists of 
a number of elements: 1 ) a Manager 40 for managing 
the activities within the MPTN General Services Ele- 
ment 36; 2) a Gateway Services Element 42 for relay- 
ing datagrams and establishing connections through 
other gateways; and 3) a Routing Services Element 
44 for maintaining an address look-up table for deter- 
mining the location of a requested end user (such as 
that defined by the Interdomain Routing Protocol, or 
IDRP) and for implementing multicast search and ver- 
ification protocols. 

Gateway 30 further consists of a Relay 48 which 
efficiently relays connections data through the Gate- 
way when a connection is established between two 
SPTNs. 

Figures 3 and 4 are graphical representations at 
a high level of the format of a basic link unit (BLU) 
which is routed throughout the MPTN 10 between 
MPTN Access Nodes, MPTN Gateways and Native 
Nodes. (A more thorough description of message for- 
mats can be found in copending application serial 
number 07/915,969). A BLU, for the purposes of this 
specification, is a packet of information being con- 
veyed between the SPTNs via the Gateway. The label 
given to the BLU is dependent upon the transport pro- 
vider protocol. For instance, if the BLU is being con- 
veyed upon a frame relay network, it is labeled a 
"frame". Or, if it is being conveyed via an asynchron- 
ous transfer mode (ATM) network, it is labeled a 
"cell". All of these various data units are BLUs for the 
purposes of this invention. 

Figure 3 illustrates a BLU as it is received at the 
MPTN Gateway 30 of the present invention from a 
Native Node, such as ND2 21 of Figure 1 . Figure 4 il- 
lustrates a BLU as it is received at the MPTN Gateway 
30 from an MPTN Access Node, such as ND1 20 of 
Figure 1. Alternatively, the BLU illustrated in Figure 4 
could be received at an MPTN Access Node from an 
MPTN Gateway. 

As shown in Figure 3, Native Node BLU includes 
a Transport Provider-specific header and trailer (TPr 
Hdr, TPr Tlr, respectively). This header and trailer is 
used for conveying the BLU through the SPTN as is 
well known in the art. The Transport Protocol header 
consists of a number of fields: a Command Type field 
(Comm Type) for identifying particular BLU type, i.e., 
whether it is a datagram or a command; a Source Ad- 
dress field (Source Add r) identifying the source trans- 
port user; a Destination Address field (Dest Addr) 
identifying the destination transport user, and a Con- 
trol field (Ctl) for providing various control functions. 
Following the Transport Header, a Transport User 
Payload field (T_User Payload) which holds the data 
that is to be conveyed between the source and the 
destination transport users. 

As shown in Figure 4, MPTN BLU, like Native 



Node BLU, includ s a Transport Provider-specific 
header and trailer. As was noted, this h ader and 
trailer is used for conveying the BLU through the 
SPTN as is well known in the art. 

5 The BLU also includes an MPTN header for pro- 

viding necessary information to the MPTN Gateway 
or Access Node. MPTN header consists of a length 
field (Len) indicating the length of the BLU. It also has 
a command-type field (Comm) for indicating the type 

10 of BLU, i.e., whether the BLU is a command such as 
Register, Locate or Connect, or whether it is a data- 
gram for forwarding. A routing information field (RI) 
contains the destination address and the source ad- 
dress of the destination and source transport users. 

is A control information field (Ctl Info) provides various 
BLU information such as "time to live", segment spec- 
ification indicating how the BLU should be reassem- 
bled if it has been disassembled during conveyance, 
etc. 

20 The BLU further has a transport user payload 

(T_User Payload) which holds the data that is to be 
conveyed between the source and the destination 
transport users. 

Routing in an MPTN environment involving an 

25 MPTN Gateway can be broken into three pieces: 

1) from the source node to the first MPTN Gate- 
way. If the source node is an MPTN node (such 
as path 33a (Fig. 1) from ND1 20 to GW1 30), 
routing from the source to the first MPTN Gate- 

30 way uses MPTN Protocols. If the source node a 

native, or non-MPTN node, (such as path 33b 
(Fig. 1) from ND2 21 to GW1 30) routing to the 
first MPTN Gateway uses the native protocols of 
the transport provider. 

35 2) between one or more MPTN Gateways (such 

as path 33b (Fig. 1) from GW1 30 to GW2 32). 
Routing between MPTN Gateways always uses 
MPTN protocols. 

3) from the last MPTN Gateway to the destination 
40 node (such as path 33b (Fig. 1) from GW2 32 to 

ND6 25). If the destination node is an MPTN node 
(such as ND6 25 (Fig. 1)), routing from the last 
MPTN Gateway to the destination uses MPTN 
Protocols. Where the destination node is a na- 
45 tive, or non-MPTN node, (such as ND7 26 (Fig. 

1)), routing from the last MPTN Gateway to the 
destination uses the native protocols of the trans- 
port provider. 

In supporting non-MPTN nodes, the MPTN gate- 
50 way must support transport providers that use both 
search based and routing-table based routing. With 
search based transport providers, the route from the 
source to the destination is not known at the time the 
connection request is made (or datagram is sent). A 
55 search is conducted to find where the destination is 
located, and then the route to the destination is cal- 
culated. Transport providers that use search based 
routing include protocols for s arching for the re- 
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quested destination and calculating the best route 
once the destination is found. Examples of search 
based transport providers include NetBIOS and SNA. 

With a routing table based protocol, the route to 
the destination is known before the connection re- s 
quest is made (or datagram sent). When a connection 
request is made (or datagram sent), the routing table 
in the node points to the "next hop" along the path in 
routing the request to the destination. Transport pro- 
viders that use a routing table based protocol include w 
routing protocols for building the "next hop" routing ta- 
bles and for maintaining the routing tables. Examples 
of routing table based transport providers include OSI 
and TCP/IP. 

To support transport providers that use a search 15 
based protocol, the MPTN Gateway must participate 
in the search and route calculation protocols. This in- 
volves a number of changes, or deltas, to the trans- 
port provider. This is shown in Fig. 5 where a native 
search request is received by MPTN Gateway 30 from 20 
a native node on SPTN 1 at 100. At 101, Transport 
Provider 1 parses the transport protocol-specific 
header and determines from the destination address 
field whether the search request must be forwarded 
to the MPTN network. If the search is to be forwarded, 25 
the transport provider will pass the search request 
across the GSPB to the Manager. At 102, the Man- 
ager determines that it is a search request, and for- 
wards the request to Gateway Services. At 1 03, Gate- 
way Services forwards the identification of the des- 30 
tination to the Routing Service Element. At 104, Rout- 
ing Services Element returns the address of the "next 
hop" to Gateway Services Element. In order to deter- 
mine the address of the next hop, the Routing Servic- 
es Element must perform a number of steps. This is 35 
shown in Fig. 5A. At 140, the Routing Services Ele- 
ment receives the destination address from the Gate- 
way Services Element. At 141, the Routing Services 
Element determines whether the destination can be 
reached by searching its routing tables for the Netld 40 
of the destination address. If not, at 142, the Routing 
Services Element returns a negative response to the 
requesting native node. If so, at 143, the Routing Ser- 
vices Element determines whether the Netld of the 
destination address is a split Netld (i.e., the network 45 
is split into two or more disjoint SPTNs and the des- 
tination could be in one of several SPTNs). If not, at 



144, the Routing Services Element returns the next 
hop to the requesting native node. If it is a split Netld, 
at 145, the Routing Services Element determines so 
whether there is a cache entry for the Netld of the 
destination address. If so, at 146, the Routing Servic- 
s Element returns the cached next hop value to the 
requesting native node. If not, at 147, the Routing 
Services Element initiates a search of each potential 55 
SPTN. This is described in cop nding application, 
Serial No. 08/58,351, entitled "Inter-Domain Multicast 
Routing". This proc dure detailed in Fig. 5A is used 

6 



whenever the Routing Services Element is requested 
by the Gat way Services Element for routing informa- 
tion. 

Referring again to Fig. 5, once it is determined 
that the destination can be reached through this 
MPTN Gateway, General Services Element responds 
to Transport Provider 1 with the positive search re- 
sponse. This is shown by steps 104-106. At 107, 
Transport Provider 1 then responds to the original 
search/verification request stating that the request- 
ed destination is located on this MPTN Gateway. The 
MPTN Gateway will subsequently receive a nativ 
connection request (or datagram). This is described 
below in conjunction with Figure 9. 

Figures 6A and 6B illustrate the message flows 
when an MPTN search is -received from another 
MPTN Gateway (MPTN GW2). At 109, a connection 
is already established between the two MPTN Gate- 
ways and, at 110, Transport Provider 2 receives a 
BLU (representing the MPTN search request) from 
MPTN GW2. At 1 11 , Transport Provider 2 parses the 
header and trailer and forwards the MPTN data and 
connection ID to the Manager. Based upon the con- 
nection ID, the Manager, at 112, forwards the MPTN 
search request to the Routing Services Element. At 
113, the Routing Services Element determines that it 
is an MPTN search request and that the Destination 
Netld is in SPTN1 (to which MPTN GW1 is providing 
access). Routing Services Element initiates a search 
request of SPTN 1 at 113. At 114, the Gateway Servic- 
es Element forwards the request to the Manager 
which, in turn, forwards the request to the Transport 
Provider 1, at 115. At 116, Transport Provider 1 ini- 
tiates the native search protocol for the requested 
destination address. 

As shown on Fig. 6B, at 117, Transport Provider 
1 receives a positive response to search from SPTN1 . 
At 118, Transport Provider 1 parses the header/trailer 
and forwards the positive response to the Routing 
Services Element (via Manager, at 119, and Gateway 
Services Element, at 120). The Routing Services Ele- 
ment, at 121, builds a positive response to the MPTN 
search and sends to the Manager which forwards the 
positive response to Transport Provider 2 at 122. At 
123, Transport Provider 2 forwards the positive re- 
sponse to the requesting MPTN GW. 

Where the MPT N search request needs to be for- 



warded to another MPTN Gateway, Gateway Servic- 
es Element will forward the MPTN search request and 
next hop Gateway address to Manager, which will for- 
ward the search request to the next MPTN Gateway. 

To support transport providers that use a routing 
tabl based protocols, the MPTN Gateway must par- 
ticipate in the routing protocols that build and main- 
tain the transport provider routing tables. This in- 
volves a numb r of changes, or deltas, to th trans- 
port provid r. The method of building transport pro- 
vider routing tables is shown in Fig. 7 while the adver- 
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tising of transport provider information is shown in 
Fig. 8. 

In Fig. 7, at 130, Transport Provider 1 learns of 
native routing information and forwards this informa- 
tion to the Manager. At 131, 132 and 133, Transport 
Provider 1, Manager and Gateway Services Element, 
respectively, forwards this information to the Routing 
Services Element. At 134, the Routing Services Ele- 
ment utilizes IDRP protocols to distribute this routing 
information to adjacent MPTN Gateways. 

Fig. 8 illustrates the message flows when MPTN 
Gateway 30 receives routing information from an ad- 
jacent MPTN Gateway. In general, when the MPTN 
Gateway receives new routing information (via the 
IDRP protocols), Routing Services Element checks 
the protocol type of the new routing information to see 
if it is the same type as any of the SPTNs this Gate- 
way supports. If they do match, the new routing infor- 
mation will be passed across the GSPB into any 
SPTN that has the same transport protocol type. This 
process of forwarding MPTN routing information into 
an SPTN is referred to as advertising. The transport 
provider then takes this routing information and prop- 
agates it through the SPTN using the native routing 
protocol of that transport provider. Subsequent native 
connect requests (or datagrams) whose destination 
routing information were advertised this way, will be 
routed to the MPTN Gateway. The transport provider 
will receive the connection request (or datagram) and 
will pass it across GSPB. This is described in Figure 
9. Using the method described above the MPTN 
Gateway provides maximum possible connectivity to 
native (non-MPTN) nodes that use routing-based pro- 
tocols. 

The specific message flows for Fig. 8 are as fol- 
lows. At 135, the Routing Services Element learns the 
new routing information and determines that it affects 
an attached SPTN. The Routing Services Element 
advertises that information into the affected SPTN. At 
1 36 and 137, the Gateway Services Element and the 
Manager respectively forward this information to 
Transport Provider 1. At 138, Transport Provider 1 
uses native routing protocols to advertise the new 
routing information. 

Figure 9 illustrates the operation of Gateway 
GW1 30 (Fig. 2) where a BLU in the form of a data- 
gram, i.e., a connectionless data packet, is to be con- 
veyed between a Native Node on SPTN 1 to a node 
(Node 2) on SPTN 2. The path from Node 1 to Node 
2 traverses Gateway 30. Node 2 could, alternatively, 
be a gateway for interconnection to another SPTN 
(i.e., SPTN 3). In the figure, the arrows indicate the 
direction of the flow of messages and the correspond- 
ing Native Node BLU (of the form shown in Figure 3) 
as it is processed. At 51, the particular Transport Pro- 
vider receiv s the BLU from the Native Node on 
SPTN 1 (to be conveyed to Node 2 on SPTN 2), pars- 
es the transport protocol-sp cif ic header (and trailer, 
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if any) and determines from the destination address 
field that Node 2 is not located in SPTN 1 and needs 
to be forwarded to another SPTN. The Transport Pro- 
vider forwards T_User Payload to the Manager at 52 

5 with parameters indicating to the Manager the trans- 
port user destination and the source addresses, re- 
quired quality of service, user characteristics, and in- 
dication that it is a datagram to be forwarded. Th 
Manager forwards the parameters and the T_User 

10 Payload to the Gateway Services Element at 53 in or- 
der to obtain routing information. Gateway Services 
Element forwards the identification of the destination 
user to the Routing Services Element at 54. Routing 
Services Element determines, from its look-up table 

15 (as illustrated in Fig. 5A discussed above), where the 
destination user is located and returns, at 55, to the 
Gateway Services Element the "next hop" thereby 
identifying the particular transport provider address 
to which the datagram needs to be forwarded, Trans- 

20 port Provider 2, in this example. At 56, the Gateway 
Services Element builds an MPTN header to the 
T_User Payload and forwards the resulting MPTN 
datagram to the Manager. At 57, Manager forwards 
the new MPTN datagram to Transport Provider 2 

25 along with the corresponding parameters to indicate 
to the Transport Provider the transport provider 
source and destination addresses of the "next hop", 
required quality of service, user characteristics, and 
indication that it is a datagram for forwarding. The 

30 Transport Provider adds the transport protocol-spe- 
cific header and trailer and transmits the resulting 
BLU onto SPTN 2 at 58. 

Figure 10 illustrates the operation of Gateway 30 
where a BLU in the form of a datagram is to be con- 

35 veyed between an MPTN Node on SPTN 1 to an 
MPTN node on SPTN 2. The path from Node>1 to 
Node 2 traverses Gateway 30. At 61, the particular 
Transport Provider receives the BLU from the MPTN 
Node on SPTN 1 , parses the transport protocol-spe- 

40 cif ic header (and trailer, if any) and determines from 
the source and destination address fields that the da- 
tagram is addressed to the well-known MPTN port on 
Gateway 30. As is known in the industry, a well- 
known port is a local address that is reserved for a 

45 specific service. Only MPTN datagrams will be ad- 
dressed to this well-known port thus the Transport 
Provider knows to forward the MPTN datagram to the 
Manager. The Transport Provider forwards the MPTN 
datagram (which includes the MPTN header and the 

so T User Payload or user datagram), and parameters 
to the Manager at 62. From the transport user ad- 
dresses in the MPTN header, the Manager determi- 
nes that it is a MPTN datagram for forwarding to an- 
other SPTN and forwards the BLU to the Gateway 

55 Services Element for routing information at 63. Gate- 
way S rvices Element forwards th identification of 
the destination user to the Routing Services Element 
at 64. Routing Services Element determines, from its 

7 
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look-up table (as described in Fig. 5A and accompa- 
nying text), where the destination user is located and 
returns, at 65, to the Gateway Services Element the 
"next hop" thereby identifying the particular transport 
provider address to which the MPTN datagram needs s 
to be forwarded. At 66, the Gateway Services Ele- 
ment forwards the MPTN datagram back to the Man- 
ager. Manager forwards the MPTN datagram to 
Transport Provider 2 at 67, along with the correspond- 
ing parameters to indicate to the Transport Provider 10 
the source and destination transport provider ad- 
dresses of the next hop and required quality of ser- 
vice. The Transport Provider adds the transport pro- 
tocol-specific header and trailer and transmits the 
BLU onto SPTN 2 at 68. 15 

Figures 11a and 11b illustrate the operation of 
Gateway 30 where a "connect" request BLU is re- 
ceived from a Native Node on SPTN 1 requesting to 
be connected to an MPTN Node on SPTN 2. The path 
from Node 1 to Node 2 traverses Gateway 30. In Fig- 20 
ure 11a, at 71, the particular Transport Provider re- 
ceives the BLU from the Native Node on SPTN 1, 
parses the transport protocol-specific header (and 
trailer, if any), recognizes from the "Command Type" 
field that it is a "connect request" from the Native 25 
Node and determines from the destination address 
field that the connect request needs to be forwarded 
to an MPTN Gateway. The Transport Provider for- 
wards the remaining portion of the BLU which in- 
cludes the TJJser Payload to the Manager at 72 30 
along with parameters giving the source and destin- 
ation user addresses, required quality of service 
transport characteristics and a "connect request" 
parameter. The Manager forwards the parameters to 
the Gateway Services Element to obtain routing infor- 35 
mation and to establish the connection to Node 2 at 
73. Gateway Services Element forwards the identifi- 
cation of the destination user to the Routing Services 
Element at 74. Routing Services Element determi- 
nes, from its look-up table (Fig. 5A and accompanying 40 
text) and, when necessary, initiates a search of the 
MPTN network, where the destination user is located 
and returns, at 75, to the Gateway Services Element 
the "next hop" thereby identifying the particular trans- 
port provider address to which the "connect request" 45 
needs to be forwarded. At 76, the Gateway Services 
Element builds an MPTN Connect which includes the 



T_User Payload and forwards the resulting "connect 
request" to the Manager. Manager forwards the con- 
nect request to the Transport Provider 2 at 77, along 50 
with the corresponding parameters to indicate to the 
Transport Provider the source and destination trans- 
port provid r addresses of the next hop, required 
quality of service, and MPTN Connect. The Transport 
Provider establishes a connection with the MPTN 55 
node on SPTN 2 and sends th MPTN Connect (with 
transport specific header and trailer) as the first data 
packet on the connection at 78. At 79, the Gateway 



Services Element sends a message, "Relay Get 
Ready", to the Manager, for forwarding to the Relay, 
at 80, to prepare for a conn ction. 

In order for a connection to be establish d, an 
"end-to-end" confirmation must be established so 
that each "hop" along the connection path is available 
for establishing the connection. In other words, the 
"connect request" BLU is forwarded throughout the 
MPTN to all of the intermediary nodes so that each is 
prepared for the connection. It is not until a "connect 
request confirmation" is received by the originating 
node that the MPTN connection is considered to be 
established. 

As shown in Figure 11b, at 81, the "MPTN Con- 
nect request confirmation" is received at Transport 
Provider 2 from Node 2 on SPTN 2. This "MPTN Con- 
nect request confirmation" indicates to the Gateway 
that the connection path is ready for user data ex- 
change. As with all BLUs, the transport-specific 
header and trailer are parsed, and the remaining 
MPTN Connect conf irmation(with parameters) is for- 
warded to the Manager for processing. The Manager 
forwards this to the Gateway Services Element which 
is responsible for the connection establishment This 
responsibility includes confirming the connection to 
the originating node, keeping the state of the MPTN 
connection, and preparing the Relay for the connec- 
tion. The Gateway Services Element forwards the re- 
suiting "connect request confirmation" BLU to Man- 
ager. The Manager knows that the original incoming 
connection request was a native request (Fig. 11a) so 
the Manager parses the MPTN Connect confirmation 
to get the needed information, including source and 
destination transport user addresses, required quali- 
ty of service, and a connect request confirmation 
parameter. The Manager forwards this to Transport 
Provider 1 at 87, along with the corresponding para- 
meters. The Transport Provider adds the transport 
protocol-specific header and trailer and transmits the 
native "connect request confirmation" BLU onto 
SPTN 1 at 88. At 89, the Gateway Services Element 
sends a message, "Relay - Connection Established", 
to the Manager, for forwarding to the Relay, at 90, to 
indicate that the connection has been established. At 
this point, the connection is established and any 
BLUs received at Transport Provider 1 from this con- 
nection will be forwarded directly to the-Relay for for- 



warding to Transport Provider 2. 

No illustration is given where there is a connec- 
tion request from an MPTN Node as the method for 
processing this request is identical to the method de- 
scribed in conjunction with Figures 11 a and 11b, ex- 
cept that ther is additional processing required for 
the MPTN header which is received with the connec- 
tion request BLU. The processing of the MPTN head- 
er is described in conjunction with Figur 10. 

Thus, it can be seen that the MPTN Gateway of 
the present invention provides transparent int rcon- 
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nection of two or more SPTNs running different trans- 
port layer protocols. The primary function of the gate- 
way is to connect individual SPTNs to form an inte- 
grated heterogeneous MPTN or internetwork. 



Claims 

1. A gateway for being interconnected between a 
first single protocol transport network (SPTN) 
running a first transport provider protocol and a 
second SPTN running a second transport provid- 
er protocol, for receiving from a node connected 
to said first SPTN a basic link unit (BLU) having 
header information conforming to said first proto- 
col, for processing said first protocol BLU to a 
BLU having header information conforming to 
said second protocol, and conveying said second 
protocol BLU to a node connected to said second 
SPTN, said gateway comprising: 

a first SPTN transport provider having means for 
receiving said first protocol BLU and means for 
processing said first protocol header information 
into a general form; 

a second SPTN transport provider having means 
for conveying said second protocol BLU to said 
second SPTN, and means for processing general 
form header information into header information 
conforming to said second protocol; and 
an element for providing general gateway servic- 
es for said first and second SPTN transport pro- 
viders comprising means for receiving general 
form header information from said first SPTN 
transport provider, means for processing said re- 
ceived general form header information, means 
for creating new general form header information 
and means for building a multiprotocol transport 
network (MPTN) header and means for convey- 
ing to said second SPTN transport provider said 
new general form header information and said 
MPTN header. 

2. The gateway defined in Claim 1 wherein said first 
protocol BLU further has an MPTN header and 
said general gateway services element further 
comprises means for receiving said MPTN head- 
er from said first SPTN transport provider, means 
for processing said MPTN header, and means for 
creating new general form header information 
based upon said received MPTN header and 
means for conveying said new general form 
header information and said MPTN header to 
said second SPTN transport provider. 

3. Th gateway defined in Claim 2 wherein said 
MPTN header processing means comprises a 
routing services element for determining the ad- 
dress of said node on said second SPTN based 



upon said received MPTN header information. 

4. The gateway defined in Claims 2 or 3 wherein 
said first SPTN transport provider further has a 

5 well-known port for determining whether said first 

protocol BLU is an MPTN BLU. 

5. The gateway of Claims 1 to 4 wherein said first 
SPTN transport provider further comprises 

10 means for conveying said first protocol BLU to 

said first SPTN and said first protocol header in- 
formation processing means comprises means 
for determining whether said first protocol BLU 
needs to be conveyed to another SPTN or needs 

is to be conveyed to said first SPTN. 

6. The gateway defined in Claim 1 wherein said 
general gateway services element further com- 
prises a routing services element for determining 

20 the address of said node on said second SPTN 

based upon said received general form header in- 
formation. 

7. The gateway of Claims 1 to 6 further comprising, 
25 in addition to said first SPTN transport provider 

and said second SPTN transport provider, a plur- 
ality of unique SPTN transport providers, differ- 
ent from said first SPTN transport provider, from 
said second SPTN transport provider and from 

30 each other, each for providing an transport pro- 

vider to an SPTN running a correspondingly 
unique transport protocol, each unique SPTN 
transport provider having means for receiving a 
BLU having header information conforming to 

35 said corresponding unique SPTN protocol, 

means for processing said unique SPTN protocol 
header information into general form header in- 
formation, means for receiving from said general 
gateway services element and processing gener- 

40 a I form header information into unique protocol 

header information and means for conveying a 
unique protocol BLU to said unique SPTN. 

8. The gateway defined in Claim 1 or 7 wherein said 
45 general gateway services element further com- 
prises a gateway services element for relaying 
datagrams from said first SPTN transport provid- 
er to said second SPTN transport provider. 

so 9. The gateway defined in Claim 8 wherein said 
gateway further comprises a relay and said gate- 
way services element establishes connections 
between said first and second SPTN transport 
providers utilizing said relay. 

55 

10. In a gateway for being interconnected betw en a 
first SPTN running a first transport provider pro- 
tocol and a second SPTN running a second pro- 
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tocol, said gateway comprising first and second 
transport providers for interfacing with said first 
and second SPTNs and further comprising a gen- 
eral gateway services element for providing gate- 
way services to said first and second transport s 
providers, a method of conveying a basic link unit 
(BLU) from said first SPTN to said second SPTN, 
said received BLU consisting of header informa- 
tion conforming to said first protocol, said method 
comprising the steps of: 10 
receiving said BLU from said first SPTN in said 
first transport provider; 

in said first transport provider, processing said 
header information into a general form under- 
stood by said general gateway services element; 15 
conveying to said general gateway services ele- 
ment said general form header information; 
in said general gateway services element, build- 
ing a multiprotocol transport network (MPTN) 
header; 20 
in said general gateway services element, creat- 
ing new general form header information based 
upon said general form header information; 
conveying to said second transport provider said 
MPTN header and said new general form header 25 
information; and 

in said second transport provider, processing 
said new general form header information into a 
header information conforming to said second 
protocol; and 30 
from said second transport provider, conveying, 
to said second SPTN, a second protocol BLU 
having said second protocol header information 
and said MPTN header. 

35 

11. The method defined in Claim 10 further compris- 
ing, before said MPTN header building step, the 
step of examining said general form destination 
address and determining an intermediary ad- 
dress and further wherein, in said building step, 40 
said MPTN header is based upon said intermedi- 
ary address. 



12. The method defined in Claim 11 wherein said 
BLU received by said first transport provider fur- 45 
ther consists of an MPTN header of a form under- 
stood by said general gateway services element 

and said building step comprises the steps of ex- 
amining said received MPTN header, determining 
an intermediary address based upon said MPTN so 
header, and creating said new general form head- 
er information based upon said intermediary ad- 
dress. 

13. Th method d fined in Claim 10 wh rein said 55 
gateway further comprises a relay for stablish- 

ing a connection through said gateway between 
said first SPTN and said s cond SPTN and said 



received BLU further has a command field con- 
forming to said first protocol, said method further 
comprising the st p, aft r said destination ad- 
dress processing step, of processing said com- 
mand field into a general form understood by said 
general services element, and, before said build- 
ing step, the step of examining said general form 
command field and, where said command is a 
CONNECT command, said building step com- 
prises building an MPTN header having an MPTN 
CONNECT command. 

14. The method defined in Claim 10 wherein said 
MPTN header building step comprises the step 
determining the address of said node on said sec- 
ond SPTN based upon said MPTN header infor- 
mation. 

15. A gateway for being interconnected between a 
first single protocol transport network (SPTN) 
running a first transport provider protocol and a 
second SPTN running a second transport provid- 
er protocol, for receiving from a multiprotocol 
transport (MPTN) node connected to said first 
SPTN a basic link unit (BLU) having header infor- 
mation conforming to said first protocol and fur- 
ther having MPTN header information, for proc- 
essing said first protocol BLU to a BLU having 
header information conforming to said second 
protocol, and conveying said second protocol 
BLU to a native node connected to said second 
SPTN, said gateway comprising: 

a first SPTN transport provider having means for 
receiving said first protocol BLU and means for 
processing said first protocol header information 
into a general form; 

a second SPTN transport provider having means 
for conveying said second protocol BLU to said 
second SPTN, and means for processing general 
form header information into header information 
conforming to said second protocol; and 
an element for providing general gateway servic- 
es for said first and second SPTN transport pro- 
viders comprising means for receiving general 
form header information and said MPTN header 
information from said first SPTN transport pro- 

v i der , me a n s for pro c ess i ng s a i d r e c e iv e d g e n e r - — 

alform header information and said MPTN head- 
er information, means for creating new general 
form header information and means for convey- 
ing to said second SPTN transport provider said 
new general form header information. 

16. The gateway defined in Claim 15 wherein said 
general gateway services element further com- 
prises means for conv ying to said second SPTN 
transport provider said MPTN header informa- 
tion. 
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17. The gateway defined in Claim 15 wherein said 
MPTN header information processing means 
comprises a routing services element for deter- 
mining the address of said node on said second 
SPTN based upon said received MPTN header 
information. 

18. The gateway defined in Claim 15 or 16 wherein 
said first SPTN transport provider further has a 
well-known port for determining whether said first 
protocol BLU is an MPTN BLU. 



22. The gateway defined in Claim 15 wherein said 
general gateway services element further com- 
prises a gateway services element for relaying 
datagrams from said first SPTN transport provid- 
er to said second SPTN transport provider. 

23. The gateway defined in Claim 22 wherein said 
gateway further comprises a relay and said gate- 
way services element stablishes connections 
between said first and second SPTN transport 



10 



1 9. The gateway of Claims 1 5 to 20 wherein said first 
SPTN transport provider further comprises 
means for conveying said first protocol BLU to 15 
said first SPTN and said first protocol header in- 
formation processing means comprises means 

for determining whether said first protocol BLU 
needs to be conveyed to another SPTN or needs 
to be conveyed to said first SPTN. 20 

20. The gateway defined in Claim 15 or 21 wherein 
said general gateway services element further 
comprises a routing services element for deter- 
mining the address of said node on said second 25 
SPTN based upon said received general form 
header information. 

21. The gateway defined in Claim 15 further compris- 
ing, in addition to said first SPTN transport pro- 30 
vider and said second SPTN transport provider, 

a plurality of unique SPTN transport providers, 
different from said first SPTN transport provider, 
from said second SPTN transport provider and 
from each other, each for providing an transport 35 
provider to an SPTN running a correspondingly 
unique transport protocol, each unique SPTN 
transport provider having means for receiving a 
BLU having header information conforming to 
said corresponding unique SPTN protocol, 40 
means for processing said unique SPTN protocol 
header information into general form header in- 
formation, means for receiving from said general 
gateway services element and processing gener- 
al form header information into unique protocol 45 
header information and means for conveying a 
unique protocol BLU to said unique SPTN. 
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providers utilizing said relay. 

24. In a gateway for being interconnected betw en a 
first single protocol transport network (SPTN) 
running a first transport provider protocol and a 
second SPTN running a second protocol, said 
gateway comprising first and second transport 
providers for interfacing with said first and sec- 
ond SPTNs and further comprising a general 
gateway services element for providing gateway 
services to said first and second transport provid- 
ers, a method of conveying a basic link unit (BLU) 
from said first SPTN to said second SPTN, said 
received BLU consisting of header information 
conforming to said first protocol and further con- 
sisting of multiprotocol transport network 
(MPTN) header information, said method com- 
prising the steps of: 

receiving said BLU from said first SPTN in said 
first transport provider; 

in said first transport provider, processing said 
header information into a general form under- 
stood by said general gateway services element; 
conveying to said general gateway services ele- 
ment said general form header information and 
said MPTN header information; 
in said general gateway services element, proc- 
essing said MPTN header information; 
in said general gateway services element, creat- 
ing new general form header information based 
upon said general form header information; 
conveying to said second transport provider said 
new general form header information; and 
in said second transport provider, processing 
said new general form header information into a 
header information conforming to said second 
protocol; and 

from said second transport provider, conveying, 
to said second SPTN, a second protocol BLU 
having said second protocol header information. 

25. The method defined in Claim 24 wherein said 
MPTN header information processing step com- 
prises the steps of examining said received 
MPTN header, determining an intermediary ad- 
dress based upon said MPTN header, and creat- 
ing said new general form header information 
based upon said intermediary address. 

26. The method defined in Claim 24 wherein said 
gateway further comprises a relay for establish- 
ing a connection through said gateway between 
said first SPTN and said second SPTN and said 
MPTN header information further has an MPTN 
command field, said MPTN header information 
processing step further comprising the step of ex- 
amining said MPTN command field and, where 
said command is an MPTN CONNECT com- 
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mand, said method further comprising the step of 
building a g nerai form command field having a 
general form CONNECT command. 

27. The method defined in Claim 24 wherein said s 
MPTN header processing step comprises the 
step determining the address of said node on said 
second SPTN based upon said MPTN header in- 
formation. 
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